Datadog で AWS PrivateLink を使ったプライベートネットワーク接続をやってみた

こんにちは。テクニカルサポートチームのShiinaです。

はじめに

SaaS の監視ツールを利用する場合、EC2 インスタンスに専用のエージェントを導入し、エージェントからインターネット経由で SaaS に通信することが多いかと思います。もちろん、Datadog もこれに当てはまります。
ここで困るのがセキュリティ要件で EC2 インスタンスから直接インターネットへの通信を禁じている環境です。
プロキシサーバを用意し、通信を中継させる方法がありますが、Datadog では AWS PrivateLink を介して Datadog に対してメトリクスやログなどを送信することができます。
今回は AWS PrivateLink を介したプライベートなネットワーク接続で Datadog にメトリクスとログの送信をやってみました。

Datadog の AWS PrivateLink エンドポイントについて

バージニア北部リージョン（us-east-1）のみでエンドポイントが公開されています。
そのため、東京や大阪リージョンから利用する場合にはリージョン間 VPC ピアリングを行い、通信を確立する必要があります。

最新情報は Datadog のドキュメント^[1]をご参照ください。

前提

• 東京とバージニア北部リージョンを利用します。
• Datadog エージェントはあらかじめ導入されていること。
• PrivateLink のエンドポイントはシングル AZ 構成とし、冗長化は考慮しません。
• Datadog エージェントからメトリクスとログの送信に必要な最低限のエンドポイントを利用します。
  メトリクス：com.amazonaws.vpce.us-east-1.vpce-svc-09a8006e245d1e7b8
  ログ (Agent HTTP インテーク)：com.amazonaws.vpce.us-east-1.vpce-svc-025a56b9187ac1f63

構成

今回利用したリソースは次の通りです。

東京リージョン

• VPC
  CIDR：10.0.0.0/16
  名前：my-vpc-vpc
• サブネット
  CIDR：10.0.2.0/24
  アベイラビリティゾーン：apne1-az4
  名前： my-vpc-subnet-private1-ap-northeast-1a

バージニア北部リージョン

• VPC
  CIDR：192.168.0.0/16
  名前：Datadog-PrivateLink-VPC
• サブネット
  CIDR：192.168.0.0/20
  アベイラビリティゾーン：us-east-1f
  名前：Datadog-PrivateLink-Subnet
• セキュリティーグループ
  名前:DatadogPrivateLinkSG
  インバウンドルールは次の通り。
  ポート:443 ソース：東京リージョンの VPC CIDR（10.0.0.0/16）を許可

グローバル

• Amazon Route 53
  プライベートホストゾーン
  ドメイン名：metrics.agent.datadoghq.com、agent-http-intake.logs.datadoghq.com

セットアップ手順

1.ネットワークリソース作成（バージニア北部）

バージニア北部リージョンにエンドポイント作成するに伴い、必要となる VPC、CIDR 、サブネット、セキュリティグループのリソースを作成しておきます。

2.エンドポイント作成（バージニア北部）

エンドポイントは２つ（メトリクス用、ログ用）作成します。
バージニア北部リージョンの VPC サービスメニューよりエンドポイントを選択します。
[エンドポイントを作成]をクリックします。
次のように設定を行います。

・名前：任意の名前
・サービスカテゴリ：その他のエンドポイントサービス
・サービス名：Datadog エンドポイントサービス名
※入力後に[サービスの検証]をクリックします。

・VPC：Datadog-PrivateLink-VPC
・DNS名を有効化：無効
・サブネット：Datadog-PrivateLink-Subnet
・セキュリティグループ：DatadogPrivateLinkSG

設定項目を入力したら[エンドポイント作成]をクリックします。

同様の手順でログ (Agent HTTP インテーク)のエンドポイントを作成してください。

作成後、２つのエンドポイントのステータスが使用可能になっていれば OK です。

3.VPC ピアリング接続、ルーティング設定（バージニア北部）

バージニア北部リージョンの VPC サービスメニューよりピアリング接続を選択します。
次のように設定を行います。

・名前：任意の名前
・VPC ID (リクエスタ)：Datadog-PrivateLink-VPC の VPC ID
・アカウント：自身のアカウント
・リージョン：別のリージョン（東京リージョン）
・VPC ID：my-vpc-vpc の VPC ID

設定項目を入力したら[ピアリング接続を作成]をクリックします。

作成すると一覧にピアリング接続 ID （pcx-xxxxxxxxx）が表示されます。
ピアリング接続 ID は後述の手順で利用するため、控えておいてください。

バージニア北部リージョンの VPC サービスメニューよりサブネットを選択します。
Datadog-PrivateLink-Subnet を選択します。
ルートテーブルをクリックします。
遷移したルートテーブルのページでルートタブを選択し、[ルートを編集]をクリックします。
以下のルートを追加します。

・送信先：10.0.0.0/16（東京リージョンのVPC CIDR）
・ターゲット：ピアリング接続 ID（pcx-xxxxxxxxx）

[変更を保存]をクリックします。

※現時点では追加したルートのステータスはブラックホール状態ですが、問題はありません。

4.VPC ピアリングリクエスト承諾、ルーティング設定（東京リージョン）

東京リージョンの VPC サービスメニューよりピアリング接続を選択します。
保留中のリクエストを選択し、アクションより[リクエストを承諾]をクリックします。

承諾後、ピアリング接続のステータスが Active となることを確認します。

東京リージョンの VPC サービスメニューよりサブネットを選択します。
my-vpc-subnet-private1-ap-northeast-1a を選択します。
ルートテーブルをクリックします。
遷移したルートテーブルのページでルートタブを選択し、[ルートを編集]をクリックします。
以下のルートを追加します。

・送信先：192.168.0.0/16（バージニア北部リージョンのVPC CIDR）
・ターゲット：ピアリング接続 ID（pcx-xxxxxxxxx）

[変更を保存]をクリックします。

ルートのステータスはアクティブとなっていることを確認します。

ピアリングリクエストが承諾されたことにより、バージニア北部リージョンのルートのステータスもブラックホールからアクティブになります。

5.Amazon Route 53 プライベートホストゾーン作成、エイリアスレコード登録

プライベートホストゾーンは２つ（メトリクス用、ログ用）作成します。

Amazon Route 53 サービスメニューよりホストゾーンを選択します。
[ホストゾーンの作成]をクリックします。

次のように設定を行います。

・ドメイン名：プライベート DNS 名（メトリクスの場合はmetrics.agent.datadoghq.com）
・タイプ：プライベートホストゾーン
・ホストゾーンに関連付けるVPC
　バージニア北部リージョン：Datadog-PrivateLink-VPC の VPC ID
　東京リージョン：my-vpc-vpc の VPC ID

設定項目を入力したら[ホストゾーンの作成]をクリックします。

次に、作成したホストゾーンを選択します。
[レコードを作成]をクリックします。

次のように設定を行います。

・レコードタイプ：Aレコード
・エイリアス：有効化にトグル
・トラフィックのルーティング先：VPC エンドポイントへのエイリアス（バージニア北部リージョン）
・エンドポイント：エンドポイントの DNS　名（メトリクスの場合はxxxx.vpce-svc-09a8006e245d1e7b8.us-east-1.vpce.amazonaws.com）
※ DNS 名はエンドポイントごとに２つ登録されるため、いずれか片方の選択で構いません。

設定項目を入力したら[レコードを作成]をクリックします。

A レコードが作成されたことを確認してください。

同様の手順でログ (Agent HTTP インテーク)のプライベートホストゾーンの作成とエイリアスレコードを登録してください。

6.名前解決の確認

Datadog エージェントが導入されている EC2 インスタンスに接続し、プライベートホストゾーンに登録したレコードを名前解決できるか確認を行います。

• ログ (Agent HTTP インテーク)

dig metrics.agent.datadoghq.com

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> metrics.agent.datadoghq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58246
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;metrics.agent.datadoghq.com.   IN      A

;; ANSWER SECTION:
metrics.agent.datadoghq.com. 60 IN      A       192.168.9.209

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Oct 23 00:19:58 UTC 2024
;; MSG SIZE  rcvd: 72

• メトリクス

dig agent-http-intake.logs.datadoghq.com
; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> agent-http-intake.logs.datadoghq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47961
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;agent-http-intake.logs.datadoghq.com. IN A

;; ANSWER SECTION:
agent-http-intake.logs.datadoghq.com. 60 IN A   192.168.10.219

;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Oct 23 00:20:23 UTC 2024
;; MSG SIZE  rcvd: 81

いずれもエンドポイントのプライベート IPアドレスが返されていれば問題なく設定できています。

7.疎通確認

エンドポイントに通信が行えるか疎通確認を実施します。

nc -w1 metrics.agent.datadoghq.com -vz 443
Connection to metrics.agent.datadoghq.com (192.168.9.209) 443 port [tcp/https] succeeded!

nc -w1 agent-http-intake.logs.datadoghq.com -vz 443
Connection to agent-http-intake.logs.datadoghq.com (192.168.10.219) 443 port [tcp/https] succeeded!

succeeded! と表示されれば問題なく疎通できています。

8.Datadog エージェント設定

エンドポイントを利用して通信を行うため、Datadog エージェントの再起動を行います。
ログをエンドポイント経由で送信する場合、 HTTPS 経由とする設定である force_use_http を true にする必要があります。
そのため、 datadog.yaml を修正の上、再起動を行います。

（中略）

logs_enabled: true
logs_config:
    force_use_http: true

（中略）

systemctl restart datadog-agent

動作確認

Datadog エージェントがエンドポイントを利用してメトリクス、ログを送信できているか確認を行います。

メトリクスの確認

Datadog コンソールメニューの Infrastructure より Hosts を選択します。
一覧より該当のホスト名を選択します。
Metrics タブの Apps より system を選択します。
各メトリクスが表示されていれば問題なくメトリクスを送信できています。

ログの確認

ログ監視設定を conf.yaml で行います。
例として /var/log/apllog を監視対象ファイルとし、ログを収集します。

logs:
  - type: file
    path: "/var/log/apllog"
    service: "apl"
    source: "webserver"

設定反映のため、Datadogエージェントを再起動します。

systemctl restart datadog-agent

監視対象ファイルに対してログメッセージの書き込みを行なってみます。

echo testmessage >> /var/log/apllog

Datadog コンソールメニューの Logs より Explorer を選択します。
書き込みを行なったログメッセージが確認できれば問題なくログを送信できています。

トラブルシューティグ

「Could not refresh Remote Config: failed to issue org data request」 のエラーが出力されている

• 事象
  エージェントログに断続的に次のエラーメッセージが出力されている。

2024-10-23 00:36:49 UTC | CORE | ERROR | (pkg/config/remote/service/service.go:469 in pollOrgStatus) | [Remote Config] Could not refresh Remote Config: failed to issue org data request: Get "https://config.datadoghq.com/api/v0.1/status": dial tcp 3.233.157.103:443: i/o timeout

• 対処方法
  リモート構成用の通信が失敗しています。
  Agent バージョン 7.47.0 以降は、デフォルトで remote_configuration.enabled が true に設定されているため、通信が発生します。
  リモート構成を利用する場合はエンドポイントの作成が必要ですが、利用しない場合はエラーメッセージは静観でも問題ありません。
  エラーメッセージを抑止したい場合は datadog.yaml の remote_configuration.enabled を true から false に変更してください。

remote_configuration:
  enabled: false

名前解決ができない

• 事象
  名前解決を行なってもプライベートホストゾーンに登録したエンドポイントが返ってこず、パブリック IP が返される。

dig  metrics.agent.datadoghq.com 

; <<>> DiG 9.10.6 <<>> metrics.agent.datadoghq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44008
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;metrics.agent.datadoghq.com.	IN	A

;; ANSWER SECTION:
metrics.agent.datadoghq.com. 300 IN	CNAME	alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.122
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.6
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.116
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.64
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.43
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.18
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.4
alb-metrics-agent-shard1-770518637.us-east-1.elb.amazonaws.com.	60 IN A	3.233.148.75

;; Query time: 1 msec
;; SERVER: 127.0.2.2#53(127.0.2.2)
;; WHEN: Wed Oct 23 09:14:24 JST 2024
;; MSG SIZE  rcvd: 260

• 対処方法
  パブリック IP で応答が返されている場合はプライベートホストゾーンでの名前解決に失敗しています。
  次に該当していないか確認しましょう。
  ・関連付け VPC の設定が正しく設定されていない
  ・VPC の DNS ホスト名が有効となっていない
  ・VPC の DNS 解決が有効となっていない

疎通できない

• 事象
  エンドポイントに対する通信がタイムアウトする。

nc -w1 metrics.agent.datadoghq.com -vz 443

nc: connect to metrics.agent.datadoghq.com (192.168.9.209) port 443 (tcp) timed out: Operation now in progress

• 対処方法
  セキュリティグループもしくはルートテーブルの設定誤りであることが多いです。
  次に該当していないか確認しましょう。
  ・エンドポイントに設定しているセキュリティグループのインバウンドルールが正しく設定されていない
  ・サブネットのルートテーブルのルート設定が正しく設定されていない
  東京側、バージニア北部側両方のサブネットのルートテーブルでのルート設定が必要ですのでご注意ください。

まとめ

Datadog の AWS PrivateLink エンドポイントを使ってメトリクスとログを送信する手順を紹介しました。
VPC ピアリングの設定、プライベートホストゾーンの作成、Datadog エージェントの設定などが必要です。
リージョン間 VPC ピアリングを行う場合、設定手順が少々ややこしい点には注意しましょう。

本記事が誰かのお役に立てれば幸いです。

参考

https://docs.datadoghq.com/agent/remote_config/?tab=configurationyamlfile#opting-out-of-remote-configuration

https://www.datadoghq.com/architecture/connect-to-datadog-over-aws-privatelink/